Minor cleanups FrozenIndexInput#93309
Minor cleanups FrozenIndexInput#93309original-brownbear merged 2 commits intoelastic:mainfrom original-brownbear:more-efficient-frozen-input
Conversation
Some random finds while working with this code. We shouldn't use a Consumer<Long> instead of a LongConsumer as we never pass `null` to the consumer. Also, way simplified the locking around the Lucene `Bytebuffer b` to simplify the code and technically make it a little faster/less-contenting as well. Plus, made use of modern Java's buffer slicing to simplify the slicing of the Lucene buffer.
original-brownbear
added
>non-issue
:Distributed/Snapshot/Restore
|
Pinging @elastic/es-distributed (Team:Distributed) |
| } finally { | ||
| preventAsyncBufferChanges.run(); | ||
| if (bufferWriteLocked == false) { | ||
| luceneByteBufPermits.acquire(Integer.MAX_VALUE); |
There was a problem hiding this comment.
No this is just a paranoid fail-safe like we had in the previous version of this, we never release. We always just acquire all of them to close the buffer for writes for good to have the same behaviour we previously had via the boolean but simpler.
There was a problem hiding this comment.
I see, thanks. I wonder if we could have some sort of ByteBuffer wrapper that we could "invalidate" such at it then prevent any reading from it.
There was a problem hiding this comment.
Let's see later I'd say. This is definitely a pattern we don't just have here but also in at least one other spot. I'm still hoping maybe we can find a way to not have to do this (passing the buffer around to other threads in general) since somehow this is never actually safe :) I'll think on it!
|
Thanks Tanguy! |
Some random finds while working with this code. We shouldn't use a Consumer<Long> instead of a LongConsumer as we never pass `null` to the consumer. Also, way simplified the locking around the Lucene `Bytebuffer b` to simplify the code and technically make it a little faster/less-contenting as well. Plus, made use of modern Java's buffer slicing to simplify the slicing of the Lucene buffer.
3 participants
Some random finds while working with this code. We shouldn't use a Consumer instead of a LongConsumer as we never pass
nullto the consumer.Also, way simplified the locking around the Lucene
Bytebuffer bto simplify the code and technically make it a little faster/less-contenting as well.Plus, made use of modern Java's buffer slicing to simplify the slicing of the Lucene buffer.